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Abstract

   This document specifies improvements to Customer Edge routers that
   help mitigate the problems that may arise when network configuration
   information becomes invalid without any explicit signaling of that
   condition to the local nodes.  This document updates RFC 7084.
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1.  Introduction

   In scenarios where network configuration information becomes invalid
   without any explicit signaling of that condition (such as when a
   Customer Edge (CE) router crashes and reboots without knowledge of
   the previously employed configuration information), hosts on the
   local network will continue using stale information for an
   unacceptably long period of time, thus resulting in connectivity
   problems.  This problem is documented in detail in [RFC8978].

   This document specifies improvements to CE routers that help mitigate
   the aforementioned problem for residential and small office
   scenarios.  It specifies recommendations for the default behavior of
   CE routers but does not preclude the availability of configuration
   knobs that might allow an operator or user to manually configure the
   CE router to deviate from these recommendations.  This document
   updates RFC 7084.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Improved Customer Edge Router Behavior

   This section specifies and clarifies requirements for CE routers that
   can help mitigate the problem discussed in Section 1, particularly
   when they employ prefixes learned via DHCPv6 Prefix Delegation
   (DHCPv6-PD) [RFC8415] on the WAN side with Stateless Address
   Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on the LAN
   side.  The recommendations in this document help improve robustness
   at the CE router (on which the user or ISP may have no control) and
   do not preclude implementation of host-side improvements such as
   those specified in [6MAN-SLAAC-RENUM].

   This document specifies additional WAN-side prefix-delegation (WPD)
   requirements to those specified in [RFC7084]:

   WPD-9:  CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
      messages upon restart events.  See Section 3.1 for further
      details.

   WPD-10:  CE routers MUST by default use a WAN-side Identity
      Association IDentifier (IAID) value that is stable between CE
      router restarts, DHCPv6 client restarts, or interface state
      changes (e.g., transient PPP interfaces), unless the CE router
      employs the IAID techniques discussed in Section 4.5 of [RFC7844].
      See Section 3.2 for further details.

   This document also replaces LAN-side requirement L-13 from [RFC7084]
   with:

   L-13:  CE routers MUST signal stale configuration information as
      specified in Section 3.5.

   Finally, this document specifies the following additional LAN-side
   requirements to those from [RFC7084]:

   L-15:  CE routers MUST NOT advertise prefixes via SLAAC or assign
      addresses or delegate prefixes via DHCPv6 on the LAN side using
      lifetimes that exceed the remaining lifetimes of the corresponding
      prefixes learned on the WAN side via DHCPv6-PD.  For more details,
      see Section 3.3.

   L-16:  CE routers SHOULD advertise capped SLAAC option lifetimes,
      capped DHCPv6 IA Address option lifetimes, and capped IA Prefix
      option lifetimes, as specified in Section 3.4.

3.1.  Automatic DHCPv6 RELEASEs

   Some CE routers are known to automatically send DHCPv6-PD RELEASE
   messages upon restart events.  However, this may inadvertently
   trigger a flash-renumbering scenario, along with the associated
   problems discussed in [RFC8978], that this document attempts to
   mitigate.

   As a result, requirement WPD-9 from Section 3 specifies that CE
   routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon
   restart events.

3.2.  Stability of IAIDs

   [RFC8415] requires that the IAID for an IA MUST be consistent across
   restarts of the DHCP client.  However, some popular CE routers are
   known to select new random IAIDs, e.g., every time the underlying PPP
   session is established or when the device is rebooted.  This could be
   the result of extrapolating the behavior described in [RFC7844] or
   simply a consequence of not storing IAIDs on stable storage along
   with failure to employ an algorithm that consistently generates the
   same IAID upon reboots.  Thus, requirement WPD-10 from Section 3
   prevents CE routers from inadvertently triggering flash-renumbering
   events on the local network.

3.3.  Interface between the WAN Side and LAN Side

   The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
   Options (PIOs) [RFC4861] corresponding to prefixes learned via
   DHCPv6-PD on the WAN side MUST NOT span past the remaining preferred
   and valid lifetimes of the corresponding DHCPv6-PD prefixes.  This
   means that the "Preferred Lifetime" and the "Valid Lifetime"
   advertised in PIOs by the CE router MUST be dynamically adjusted such
   that they never span past the remaining preferred and valid lifetimes
   of the corresponding prefixes delegated via DHCPv6-PD on the WAN
   side.

   Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA
   Address options and DHCPv6 IA Prefix options employed with DHCPv6 on
   the LAN side MUST NOT span past the remaining preferred and valid
   lifetimes of the corresponding prefixes learned via DHCPv6-PD on the
   WAN side.  This means that the "preferred-lifetime" and "valid-
   lifetime" of DHCPv6 IA Address options and DHCPv6 IA Prefix options
   employed with DHCPv6 on the LAN side MUST be dynamically adjusted
   such that they never span past the remaining preferred and valid
   lifetimes of the corresponding prefixes delegated to the CE router on
   the WAN side via DHCPv6-PD.

   RATIONALE:

   *  The lifetime values employed for the "Preferred Lifetime"
      (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of
      SLAAC Prefix Information Options must never be larger than the
      remaining lifetimes of the corresponding prefixes (as learned via
      DHCPv6-PD on the WAN side).  This is in line with the requirement
      from Section 6.3 of [RFC8415], which states:

   |  In particular, if the delegated prefix or a prefix derived from it
   |  is advertised for stateless address autoconfiguration [RFC4862],
   |  the advertised preferred and valid lifetimes MUST NOT exceed the
   |  corresponding remaining lifetimes of the delegated prefix.

   *  The lifetime values of prefixes advertised on the LAN side via
      SLAAC must be dynamically updated (rather than static values);
      otherwise, the advertised lifetimes would eventually span past the
      DHCPv6-PD lifetimes.

   *  The same considerations apply for the "valid-lifetime" and
      "preferred-lifetime" of IA Address options and IA Prefix options
      employed with DHCPv6 on the LAN side.

3.4.  LAN-Side Option Lifetimes

   CE routers SHOULD override the default lifetime values of Neighbor
   Discovery options that depend in any way on changes in the prefix
   employed for address configuration on the LAN side, and employ
   shorter lifetime values to improve the robustness to renumbering
   events, while complying with the requirements from Section 3.3 of
   this document and the recommendations in [RFC7772].

   CE routers SHOULD set the "Router Lifetime" of Router Advertisement
   (RA) messages to ND_PREFERRED_LIMIT.

   CE routers SHOULD also set the PIO "Preferred Lifetime" to the lesser
   of the remaining preferred lifetime of the corresponding prefix (see
   Section 3.3) and ND_PREFERRED_LIMIT, and set the PIO "Valid Lifetime"
   to the lesser of the remaining valid lifetime of the corresponding
   prefix and ND_VALID_LIMIT.  Additionally, the "Route Lifetime" of
   Route Information Options (RIOs) [RFC4191], the "Lifetime" of
   Recursive DNS Server (RDNSS) options [RFC8106], and the "Lifetime" of
   DNS Search List (DNSSL) options [RFC8106] SHOULD be set to the lesser
   of the longest remaining valid lifetime of a prefix (leased via
   DHCPv6 on the WAN side) and ND_VALID_LIMIT, if any of these options
   are included in Router Advertisement messages.

      NOTE: In scenarios where the valid lifetime and the preferred
      lifetime of prefixes learned via DHCPv6 on the WAN side are always
      larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively,
      the lifetime values advertised on the LAN side will not experience
      actual changes.

   The above text refers to the Neighbor Discovery options that are
   typically employed by CE routers.  A CE router may need to apply the
   same policy for setting the lifetime of other Neighbor Discovery
   options it employs, if and where applicable.

   CE routers providing stateful address configuration via DHCPv6 SHOULD
   set the "preferred-lifetime" of a DHCPv6 IA Address option to the
   lesser of the remaining preferred lifetime of the corresponding
   prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-
   lifetime" of the same option to the lesser of the remaining valid
   lifetime of the corresponding prefix and ND_VALID_LIMIT.

   CE routers providing DHCPv6-PD on the LAN side SHOULD set the
   "preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of
   the remaining preferred lifetime of the corresponding prefix (see
   Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-lifetime" of
   the same option to the lesser of the remaining valid lifetime of the
   corresponding prefix and ND_VALID_LIMIT.

   RATIONALE:

   *  The "Valid Lifetime" and "Preferred Lifetime" of PIOs have a
      direct impact on three different aspects:

      -  The amount of time hosts may end up employing stale network
         configuration information (see [RFC8978]).

      -  The amount of time CE routers need to persist trying to
         deprecate stale network configuration information (e.g., to
         handle cases where hosts miss Router Advertisement messages and
         thus still consider the stale information as valid).

      -  The amount of information that CE routers need to maintain
         when, e.g., multiple crash-and-reboot events occur in the time
         span represented by the option lifetimes employed on the LAN
         side.

   *  CE routers need not employ the (possibly long) WAN-side DHCPv6-PD
      lifetimes for the "Valid Lifetime" and "Preferred Lifetime" of
      PIOs sent in Router Advertisement messages to advertise sub-
      prefixes of the leased prefix.  Instead, CE routers SHOULD use
      shorter values for the "Valid Lifetime" and "Preferred Lifetime"
      of PIOs, since subsequent Router Advertisement messages will
      nevertheless refresh the associated lifetimes, leading to the same
      effective lifetimes as specified by the WAN-side DHCPv6-PD
      lifetimes.

   *  Similarly, CE routers need not employ the (possibly long) WAN-side
      DHCPv6-PD lifetimes for the "valid-lifetime" and "preferred-
      lifetime" of IA Address options and IA Prefix options employed by
      DHCPv6 on the LAN side, since the renewal of bindings by DHCPv6
      clients will lead to the same effective lifetimes as specified by
      the WAN-side DHCPv6-PD lifetimes.

3.5.  Signaling Stale Configuration Information

   When a CE router provides LAN-side address-configuration information
   via SLAAC:

   *  A CE router sending RAs that advertise prefixes belonging to a
      dynamically learned prefix (e.g., via DHCPv6-PD) SHOULD record, on
      stable storage, the list of prefixes being advertised via PIOs on
      each network segment and the state of the "A" and "L" flags of the
      corresponding PIOs.

   *  Upon changes to the advertised prefixes, and after bootstrapping,
      the CE router advertising prefix information via SLAAC proceeds as
      follows:

      -  Any prefixes that were previously advertised by the CE router
         via PIOs in RA messages, but that have now become stale, MUST
         be advertised with PIOs that have the "Valid Lifetime" and the
         "Preferred Lifetime" set to 0 and the "A" and "L" bits
         unchanged.

      -  The aforementioned advertisements MUST be performed for at
         least the "Valid Lifetime" previously employed for such
         prefixes.  The CE router MUST advertise this information with
         unsolicited Router Advertisement messages, as described in
         Section 6.2.4 of [RFC4861], and MAY advertise this information
         via unicast Router Advertisement messages when possible and
         applicable.

            NOTE: If requirement L-16 (Section 3) is followed, the
            "Valid Lifetime" need not be saved, and the stale prefix can
            simply be advertised for a period of ND_VALID_LIMIT.

   *  CE routers receiving DHCPv6 IA Prefix options with a 0 "valid-
      lifetime" MUST advertise the corresponding sub-prefixes (as they
      would be generated for the same leased prefix with a non-zero
      lifetime) with PIOs with both the "Preferred Lifetime" and the
      "Valid Lifetime" set to 0, for at least the WAN-side DHCPv6-PD
      "valid-lifetime", or for a period of ND_VALID_LIMIT if the
      recommended lifetimes from Section 3.4 are employed.

   When a CE router provides LAN-side DHCPv6 (address assignment or
   prefix delegation), then:

   *  The CE router SHOULD record, on stable storage, the DHCPv6 address
      and delegated-prefix bindings corresponding to the LAN side.

   *  If the CE router finds that the prefix to be employed for address
      assignment and/or prefix delegation has changed (e.g., upon a
      crash-and-reboot event) or the CE router receives DHCPv6 IA Prefix
      options with 0 lifetimes, the CE router MUST:

      -  In Replies to DHCPv6 Request, Renew, and Rebind messages, send
         IA Address options or IA Prefix options (as appropriate) for
         any address assignments or prefix delegations for the stale
         prefixes.  The aforementioned options MUST be sent with both
         the "valid-lifetime" and the "preferred-lifetime" set to 0, for
         at least the "valid-lifetime" originally employed for them, or
         for a period of ND_VALID_LIMIT if the recommended lifetimes
         from Section 3.4 are employed.

      -  Initiate sending Reconfigure messages, if possible (i.e.,
         client requests Reconfigure support and the CE router offers
         it), to those clients with address assignments or prefix
         delegations for the stale prefixes.

   RATIONALE:

   *  IPv6 network renumbering is expected to take place in a planned
      manner with old/stale prefixes being phased out via reduced prefix
      lifetimes while new prefixes (with normal lifetimes) are
      introduced.  However, a number of scenarios may lead to the so-
      called "flash-renumbering" events, where a prefix being employed
      on a network suddenly becomes invalid and replaced by a new prefix
      [RFC8978].  One such scenario is when an Internet Service Provider
      (ISP) employs dynamic prefixes and the CE router crashes and
      reboots.  The requirements in this section are meant to allow CE
      routers to deprecate stale information in such scenarios.

   *  The recommendations in this section expand from requirement L-13
      in Section 4.3 of [RFC7084] and Section 6.3 of [RFC8415].

   *  Hosts configuring addresses via SLAAC on the local network may
      employ addresses configured for the previously advertised prefixes
      for at most the "Valid Lifetime" of the corresponding PIOs of the
      last received Router Advertisement messages.  Since Router
      Advertisement messages may be lost or fail to be received for
      various reasons, CE routers need to try to deprecate stale
      prefixes for a period of time equal to the "Valid Lifetime" of the
      PIO employed when originally advertising the prefix.

   *  The requirements in this section to store information on stable
      storage are conveyed as "SHOULD" (as opposed to "MUST"), since
      they may represent a challenge for some implementations.

   *  Advertising DHCPv6-leased prefixes with zero lifetimes on the LAN
      side would handle the case where a CE router has no stable storage
      but receives the prefixes via DHCPv6 with 0 lifetimes.

   *  The above text does not include DHCPv6 Advertise messages sent in
      response to DHCPv6 Solicit messages, since Section 18.3.9 of
      [RFC8415] requires that a DHCPv6 server that is not going to
      assign an address or delegated prefix received as a hint in the
      Solicit message MUST NOT include that address or delegated prefix
      in the Advertise message.  Additionally, any subsequent Request
      messages will trigger the response specified in this section and
      therefore cause the address or prefix to be deprecated.

4.  Recommended Option Lifetimes Configuration Values

   *  ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)

   *  ND_VALID_LIMIT: 5400 seconds (90 minutes)

   RATIONALE:

   *  These values represent a trade-off among a number of factors,
      including responsiveness and possible impact on the battery life
      of connected devices [RFC7772].

   *  ND_PREFERRED_LIMIT is set according to the recommendations in
      [RFC7772] for the "Router Lifetime", following the rationale from
      Section 3.2 of [RFC8978].

   *  ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some
      additional leeway before configuration information is finally
      discarded by the hosts.

5.  IANA Considerations

   This document has no IANA actions.

6.  Security Considerations

   This document discusses a problem that may arise, e.g., in scenarios
   where dynamic IPv6 prefixes are employed, and it proposes
   improvements to CE routers [RFC7084] to mitigate the problem for
   residential or small office scenarios.  It does not introduce new
   security issues; thus, the same security considerations as for
   [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply.
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